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PRE-APPEAL BRIEF REQUEST FOR REVIEW 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

Claims 1-31 remain pending in the application. Reconsideration of the present case is earnestly 
requested in light of the following remarks. The Examiner rejected claims 1-5, 7-12, 14 and 17-31 under 
35 U.S.C. § 103(a) as being unpatentable over Carre (U.S. Patent 6,282,579) in view of Hamilton et al. 
(U.S. Patent 5,758,186) (hereinafter "Hamilton"), and claims 6, 13, 15 and 16 as being unpatentable over 
Carre in view of Hamilton and fiarther in view of Kung et al. (U.S. Patent 6,775,267) (hereinafter "Kung). 
Applicants note the following clear errors in the Examiner's rejection. 

In regard to claim 1, Carre in view of Hamilton fails to teach or suggest a client seneratins a 
request for type information for an attribute or event pertaining to management of one or more 
managed network objects, wherein each managed network object is a computer programming 
language object representing one or more devices on a network . The Examiner erroneously equates 
any address conversion performed as part of any remote procedure call with a client specifically 
generating a request for type information for an attribute or event pertaining to management of one or 
more managed network objects. Performing an address conversion does not teach or suggest a client 
generating a request for type information. Carre describes how objects interact and communicate using a 
CORBA infrastructure passages (Abstract, FIG. 2A, 2B, as well as column 3, line 18 to column 4, line 62 
and column 6, lines 10-35). Carre's system converts an address type with an address value according to 
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one addressing mode to a corresponding type of another specification language or addressing mode 
(Carre, column 1, line 59 - column 2, line 6; column 2, lines 11-14; lines 25-28; and lines 34- 39). 
Converting address types and object interfaces as part of a protocol conversion, as taught by Carre in view 
of Hamilton, does not include a client generating a request for type information. 

Clients in Carre's system do not generate requests for type information, but instead request a 
specific service from a particular server object (Carre, column 3, lines 47-53). In a system resulting from 
the Examiner's combination of Carre and Hamilton, type and address conversion may take place, without 
the agent (client) knowing that such conversions are performed on the parameters, data, and addresses of 
various requests between Carre's manager and agent objects and without the agent (client) seneratins a 
request for type information for an attribute or event. Moreover, there is no need in Carre's system for a 
client to generate a request for type information for an attribute or event. In fact, a main purpose of 
Carre's teachings is to perform the address type conversion for the client so that the client does not 
have to modify it's own interface in order to communicate with an object employing a different 
addressing mode. See, e.g., col. 1, line 43 - col. 2, line 6. Therefore, Carre actually teaches away 
from a client generating a request for type information for an attribute or event. 

Furthermore, Carre in view of Hamilton also fails to disclose sending the request for type 
information generated by a client to an object request broker. The Examiner relies on Hamilton, 
again citing Hamilton, Fig. 1, abstract, column 3, lines 4-67 and column 4, lines 14 - 60. Like Carre, 
Hamilton does not teach or suggest anything about sending a request for type information to an object 
request broker. In the Advisory Action, the Examiner erroneously equates the automatic type and 
conversions performed as part of a protocol translation with the specific limitation of a client generating a 
request for type information. Specifically, the Examiner refers to "managing operations such as OSI 
objects on the Agent upon requests from the Manager unit" and cites item M of Fig. 2a from Carre. 
However, Carre (in view of Hamilton) does not describe the manager unit as sending a request for type 
information or receiving a request for type information generated by a client. The cited art's data 
marshalling and method invocations may involve address conversion, but do not involve sending a 
request (generated by a client) for type information to an object request broker. 

Furthermore, Carre in view of Hamilton further fails to disclose a metadata gateway 
receiving the request for type information from the object request broker and reading the type 
information from a metadata repository, wherein the type information is stored in a database 
format in the metadata repository. Please refer to Apphcants' Response to Final Action filed August 6, 
2007 for a detailed argument regarding these limitations. 
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Carre in view of Hamilton also fails to disclose the client receiving the translated type 
information for the attribute or event through the object request broker . The Examiner cited portion 
of Carre is part of a description of converting objects from ASN to IDL and vice versa as well as caching 
of converting object instances. As described above, converting CMISE and CORBA objects is not the 
same as chent generating a request to type information, and receiving the translated type information for 
the attribute or event through an object request broker. Carre and Hamilton both teach remote procedure 
call mechanism for executing remote methods over a network. Clients in Carre's system, even if 
combined with Hamilton, do not receive any translated type information through an object request broker. 
Automatic address and/or type conversions performed as part of Carre's protocol translation are 
performed on communication message sent between Carre 's agent and manager units. The converted 
data, parameters and address are sent to the receiving object. Any address or other information converted 
or translated by Carre's system is not returned to the object or unit sending the request. 

Regarding claim 10, Carre in view of Hamilton fails to teach or suggest a cUent generating a 
request to encode type information for an object, attribute, or event pertaining to management of 
one or more managed network objects, wherein each managed network object is a computer 
programming language object that represents one or more devices on a network. The Examiner 
refers to Agent 1 of FIG. 3a, equating Agent 1 to the client of claim 10. However, clients in Carre's 
system do not generate requests to encode type information for objects, attributes or events. Instead, 
client objects in Carre's system invoke services provided by server objects, via a standard CORBA 
interface (Carre, column 1, lines 9-19; column 1, line 59-column 2, line 46; column 5, lines 49-59). 
Carre's address conversion has nothing to with a client generating a request to encode type information 
for an object, attribute or event. Instead, Carre's address type conversion is performed as part of 
communicating with CMISE object that appear as CORBA objects. 

Additionally, Carre in view of Hamilton does not teach or suggest sending the request to 
encode type information to an object request broker. The Examiner cites ORB and CMISE Gateway 
of FIG. 3a. However, the ORB of Carre, even if combined with Hamilton, does not receive a request to 
encode type information from a client. Instead, Carre teaches object request brokers provide an 
infrastructure that enables objects to communicate in a distributed environment such that "it makes no 
difference" to the requesting objects in which computer system or in which form the target object is 
implemented (Carre, column 3, lines 56-63). 
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Carre in view of Hamilton also fails to teach or suggest a metadata gateway receiving the 
request to encode type information from the object request broker. The Examiner relies on 
Hamilton, citing Fig. 1, column 3, lines 4-67 and column 4, lines 14 - 60. As noted above, the cited 
passages of Hamilton describe a remote procedure call mechanism. Nowhere does Hamilton, even in 
view of Carre, teach or suggest a metadata gateway receiving the request to encode type information from 
the object request broker. 

Carre in view of Hamilton further fails to teach or suggest storing the type information in a 
metadata repository, where the type information is stored in a database format in the metadata 
repository. The Examiner does not mention this limitation in the rejection of claim 10 at all. The 
Examiner has previously referred to Carre's conversion of address types from OSI types. However, these 
portions of Carre refer to the caching of structures, such as object instance values and object reference 
pairs for addresses already in an entity. Caching of object values and references is not the same as storing 
type information in a database format in a metadata repository. Additionally, as noted above regarding 
the rejection of claim 1, the CMISE/IDL interface unit of Carre is clearly a communication interface that 
allows non-CORBA objects to be interacted with via standard CORBA interfaces (Carre, column 5, lines 
21-39). The CMISE/IDL interface unit is clearly not a metadata repository. Please refer to Applicants' 
remarks above regarding the rejection of claim 1 and to Applicants' Response to Final Action, filed 
August 6, 2007 (pp. 8-11) for a more discussion regarding the rejection of claim 10. 

Regarding claim 14, Carre in view of Hamilton fails to teach or suggest a metadata 
repository comprising metadata concerning object classes for a plurality of managed objects, 
wherein the metadata comprises information expressed in a database format, and wherein the 
managed objects are computer programming language objects corresponding to managed devices 
on a network. The Examiner cites CMISE/IDL of FIG. 3a as well as the abstract, FIGs 2A, 3A, column 
3, lines 18-55 and column 5, lines 4-38 of Carre. However, as noted above, regarding the rejections of 
claim 1 and 10, the CMISE/IDL interface unit cited by the Examiner is clearly a communication interface 
that allows non-CORBA objects to be interacted with via standard CORBA interfaces (Carre, column 5, 
lines 21-39). The CMISE/IDL interface unit is clearly not a metadata repository. 

Carre in view of Hamilton also fails to teach or suggest a metadata gateway coupled to the 
metadata repository and to an object request broker, where the metadata gateway is operable to send and 
receive metadata from the database, where the metadata gateway provides translation of the metadata to 
and from the database format and an interface definition language . The Examiner admits that Carre fails 
to teach this limitation of claim 14 and relies on Hamilton, again citing Fig. 1, column 3, lines 4-67 and 
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column 4, lines 14 - 60. However, Hamilton's remote procedure call mechanism, even if combined with 
Carre's teachings, does not involve, nor pertain to, a metadata gateway that provides translation of 
metadata to and from a database format and an interface definition language. Hamilton teaches that 
protocol-dependent values that match a method descriptor are located in a database and passed to a server 
stub that executes the method indicated by the method descriptor (Hamilton column 1, line 56 - column 
2, line 34; FIG. 3; column 5, lines 20-39; and column 6, lines 23-45). Hamilton does not teach any 
translation of metadata to and from a database format and an interface definition language. Instead, 
Hamilton, even when combined with Carre, teaches that values (e.g., protocol-dependent values) are 
located in a database and passed without translation to server stub processes for use when executing an 
indicated method. Please refer to Applicants' Response to Final Action, filed August 6, 2007 (pp. 12-13) 
for a more discussion regarding the rejection of claim 14. 

The Examiner's rejection of many of the dependent claims is additionally erroneous. For 
example, the cited art is clearly insufficient to support the rejection of claims 2, 11, 17, 23 and 28 as 
discussed in detail in Applicants' previous response on pp. 8, 11-12 and 14-15. 

In hght of the foregoing remarks. Applicants submit the application is in condition for allowance, 
and notice to that effect is respectfially requested. If any extension of time (under 37 C.F.R. § 1.136) is 
necessary to prevent the above referenced application from becoming abandoned, Apphcants hereby 
petition for such an extension. If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 501505/51 8 1-46200/RCK. 

Respectfially submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: September 4, 2007 
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